BDD (Behavior Driven Development) 行為開發驅動方法是TDD更進一步的實踐方式，你可能想說TDD的實踐方式已經有點神奇了，怎麼還有一個叫BDD的加強版。其實大體上BDD是以TDD的方式在寫test code，但是開發前期加入了更多非工程師的元素。

舉例來說，我們在寫unit test之前要先規劃test case，例如之前在MVVM章節舉的例子，PM開了一個task讓我們query特定的user list到UI來顯示，如果沒有其他人參與測試規劃的話test case就是工程師自已想，比如說我們舉的test case例子只有一個就是成功收到正確的user list資料，但現實世界不可能這麼單純，如果server request fail怎麼辦？或是如果user list為empty是否也要考慮？所以從頭到尾只有工程師自己參與的壞處就是球員兼裁判只寫自已想測試的case，如果工程師有沒想到或是不想做的test case那當然就不會被測試到。

而BDD就是改善前期test case定義這一個部份，給所有參與專案的人一起加入規畫。因為Developer，PM，QA每個角色會考慮的層面不同，一起規劃test case會讓更多的狀況被包涵進來，也就讓整個測試更加完整。但你可能會想coding的人是工程師，如果QA或PM自已寫document要怎麼讓工程師看懂？更難的是要怎麼驗證及管理工程師寫的test case？

我們可以藉由Cucumber這個Library的協助。Cucumber是一個很強大的BDD工具，support各種主流的程式語言，因為我們用Kotlin或Java都是JVM based，所以首先我們先在build.gradle裡面加入dependency

dependencies {
    testImplementation 'io.cucumber:cucumber-java8:4.3.1'
    testImplementation 'io.cucumber:cucumber-junit:4.3.1'
}

加人dependency後基本上你就可以開始套用BDD的流程了。如果你不想使用Cucumber的flow，加入這個dependency也不會有影響，你一樣可以使用之前提過JUnit來正常操作其他已存在的test case。

Cucumber的BDD流程

我們來看一下BDD的流程圖，BDD整個包涵的範圍是從PM寫出Story開始到整個開發結束，而TDD只有從寫Test case開始到開發結束。那怎樣把PM的需求Story轉為可程式化的步驟，就要靠Cucumer的協助了，而Cucumber怎麼幫助我們做這件事？就是利用Gherkin描述檔，這也是cucumber的精神所在。首先我們會把Story轉換為Gherkin format的feature描述檔案。並且把用簡單口語的方式描述基本定義使得大家都可以參與寫作，可以概分為以下五步驟

Gherkin標記語法

• Feature
  用來描述這個檔案
• Scenario
  用來描述這個測試，一個feature檔可有多個scenario也就是test case
• Given
  描述test case的預設測試條件，等同我們之前在MVP或MVVM測試所提到的mock部份或是預設變數。
• When
  描述這個test case要做什麼事，等同我們執行Presenter或ViewModel的測試function
• Then
  描述這個test case最後要驗證什麼事，等同mockk的verify區塊或assertEquals。

在回到MVP的章節的task，在Main page裡要顯示username，這時就可依下述定義來請PM來寫這個test case，可以用很口語的方式寫成如下，看起來有沒有很簡單，當然Gherkin語法還有一些應用，可以做一些dataset的template，但是對我們做測試影響不大，我們可以用很多方式給mocking data，因此這裡先不介紹。

Feature: Main page ui

Scenario: loading user in main page
Given username from server
When request username in main page
Then received username in main page

結論

透過口語化的寫法對任何一個team member都很容易加入參與整個專案的測試，可以歸納出有下面優點

• Gherkin是文字檔，用windows notepad就可以不用特定軟體就可以開發
• PM或QA可以針對需求制定相關的驗證條件
• 整合到CI/CD後可以直接看cucumber的report
• 在TDD開發前除了一堆task敘述外，還有Given/When/Then這種有階層的描述細節可以參考

當然最後的實作者是工程師，即便BDD前期做的很好還是得靠工程師來完成。如果PM開了一堆Scenario但工程師寫錯PM也無法驗證，所以要推BDD是需要上下一心才能完成的事情。

當這些描述檔完成後，Cucubmer就會幫我們把Gherkin的描述檔轉為我們在實作Test case所需的test function，下一個章節我們會利用Android Studio實作這一部份。